home *** CD-ROM | disk | FTP | other *** search
Text File | 1990-02-23 | 3.6 KB | 72 lines | [TEXT/GEOL] |
- Item forwarded by A33 to A34
-
- Item 8918850 16-Feb-90 23:18PST
-
- From: D4384 US Voting Mach, Sarner, Calvin,PRT
-
- To: MACAPP.TECH$ MacApp Technical
-
- Sub: Persistence and Metadata
-
- I am just back in town, and find my mailbox full of persistence and metadata
- discussion. So here's my reactions:
-
- James,
- I agree that TDocument is sometimes more trouble than it is worth. If Apple
- solves all our problems with its next incarnation I would be thrilled, but I'm
- not holding my breath. In the meantime, I have work to do.
- Yes, databases are wily dragons, and I have tricked a few into submission
- myself (though grudging submission at best, dragons being dragons). I have been
- nearly drowning in the OOPS/OODBMS literature for a few years now, and agree it
- would be unwise for us as guerillas to attempt to solve the object oriented
- database problem in all its generality (if I could do it that easily I'd be
- looking for venture capital). But products like ONTOS and Inside/Out are big,
- expensive, and far more powerful than needed for many purposes, and the very
- general models of data that they enforce can be inappropriate to many more
- specialized needs.
- Both Larry and I, and I suspect many others, have independently solved
- various problems, some suprisingly subtle, relating to common problems like
- "how do I get data objects in and out of documents without reinventing the
- wheel or leasing a Cadillac" and "how do I load my customers' 5 megabyte
- document into 256K of RAM without making them wait for virtual memory, which
- will never run on their Mac Plus anyway". So I am asking, what can we learn
- from this experience, and what can be abstracted out for reuse by future
- MacAppers.
-
- Larry,
-
- I agree with you and Edmund that virtual objects and persistent objects are
- independent capabilities. But when you have both they do interact, and can
- share some of the same mechanisms, so I have found it useful to implement them
- together. In my last implementation objects could be virtual, persistent, both,
- or neither, without anyone using the objects needing to know which was which.
- The reason to include field type information with the metadata is so that
- applications can deal in limited ways with data whose classes they know nothing
- about. For instance, I can imagine an object compression/decompression utility
- that could use the field type data to choose its algorithms without needing to
- be linked to any of the methods for the classes in the data.
- I still think metadata belongs in the resource fork: partly because it just
- seems more like a resource to me (in line with Ken's and Edmund's comparisons
- to TView), but mostly because the resource manager would make it trivial to
- connect class names, ids, and field type data. I hate to solve problems that
- have been already solved in ROM. I don't know anything about System 7 IPC, but
- it doesn't sound that hard to send the metadata resources separately from the
- data.
-
- Metadata discussants,
-
- Cleary, life will be easier when Object Pascal gives us more metadata (try
- it as a chant: Give me an M…). But we waited years for 3.1, so we need to find
- solutions that work now. I still think that the Fields methods could be used as
- part of a default I/O system, along the lines Edmund and Geoff suggest, while
- retaining the flexibilty that Larry rightly insists on. I am less convinced
- that the information in .SYM files could be so used, although I could imagine a
- shell script that read through a .SYM file and automatically wrote all the
- Fields methods. Perhaps one of our shell experts is up to this one.
-
- Yours truly,
-
- Greg Colvin
-
-
-